Is the properties-ruby gem overkill here? Maybe a TESTCONTAINERS_HOST env variable could serve the same purpose without adding a new dependency. 🙂

The properties-ruby gem also seems really old and unmaintained which could cause problems in the future!

I think we should support both TESTCONTAINERS_HOST and ~/.testcontainers.properties but I agree with @HeyNonster in the concerns about the properties-ruby gem, I'll implement the .properties reader manually in Utils class keeping the same API of properties-ruby.

I'll implement the .properties reader manually in Utils class keeping the same API of properties-ruby

Great! @guilleiguaran LMK once it is available and I can rework the PR.

I think we should support both TESTCONTAINERS_HOST and ~/.testcontainers.properties

TESTCONTAINERS_HOST is not an env var in the libraries but there are others to make other Container Runtimes work with Testcontainers.

TESTCONTAINERS_HOST is not an env var in the libraries but there are others to make other Container Runtimes work with Testcontainers.

While not currently an env var, I think it would be useful to be able to use it. For example, instead of:

tc_host = properties.get(:"tc.host")

We could have:

tc_host = ENV["TESTCONTAINERS_HOST"] || properties.get(:"tc.host")

Or swap the order of the two depending on which value you'd like to take precedence. Let me know what you think! :)

Thanks for the feedback and sorry for not providing the context when submitting the PR.

The support for tc.host is a specific integration mechanism with Testcontainers Desktop and Testcontainers Cloud (although in theory, other providers could integrate through the same way). In order to ensure a consistent experience with other languages when integrating with Testcontainers Cloud and Testcontainers Desktop, tc.host should not be resolved through an ENV variable, but only be read from .testcontainers.properties in the user home dir (where the application update the value accordingly).

I think what is related to the goal of the discussion here, is supporting DOCKER_HOST as an environment variable, which is idiomatic with other Testcontainers languages as a more generic way of configuring the Docker host.

Hi @guilleiguaran, any update to support reading properties files?

Hey Guys, I hope you're doing well In this PR I pretended to add support to ~/.tescontainers.properties files but using Java Properties https://github.com/jnbt/java-properties

Let me know if this is a good option for you

Posdata: the pipeline is broken because an specific error trying to pooling the version 3.3.0-rc1:

Error: Error: Unavailable version 3.3.0-rc1 for ruby on ubuntu-24.04

Reviewed and merged #81